NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/12594

Internet Message Format | 1996-08-05 | 3.1 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c
Subject: Re: casting const
Date: Mon, 01 Apr 96 20:43:04 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4jf4f5$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4jf4f5$[e-mail]>
           [e-mail] "Rob Catling" writes:

>
>I was wondering why you could pass a char * value as an argument to
>func(const char *) with no problem, but passing char ** value to
>func(const char **) gives a compiler warning (unless you cast it).

You have to consider what const gives you. It is basically a promise that
something won't be modified through an lvalue derived from the declaration.
Importantly you also get some verification of this from the compiler which
can only be bypassed using casting. The problem is that if the language
allowed assignment of a char ** to a const char ** (or similarly passing
a char ** argument to a const char ** parameter) you could bypass this
guarantee without either a compiler diagnostic or a cast. Consider:

    const char c, *cp, **cpp;
    char     *p, **pp;

    cp = &c;

    pp = &p;      /* Create our (char **) value - the address of p */

    cpp = pp;     /* The illegal step - assign char ** to const char **
                     cpp now points to p. */

    *cpp = cp;    /* Assign a (const char *) to a (const char *) which is
                     legal. We've now managed to assign a const char *
                     value to p by creating an lvalue (i.e. *cpp) that
                     doesn't match the object */

    *p = 1;       /* And c has now been modified */


>The comp.lang.c FAQ was the only place that told me why I had to cast a
> function
>argument to (const **), however I'm still wondering:
>
>1) how was this pieced together from the references? ANSI C ref and H&S failed
>   to illuminate this for me.

ANSI 6.3.16.1 has a set of constraints, one of which is required to hold. The
only one relevant here is:

" - both operands are pointers to qualified or unqualified versions of
    compatible types, and the type pointed to by the left has all the
    qualifiers of the type pointed to by the right;"

So (using the definitions above):

    cp = p;

is fine because char is compatible with itself and const char has every
qualifer that char has (none on this case).

    cpp = pp;

is illegal because cpp is a pointer to const char * and pp is a pointer
to char * - const char * and char * are incompatible types.

>2) is this really an elegant language feature or a practical kludge ?

It is nearly an elegant feature. The problem is that C doesn't allow
you to assign (char **) to (const char *const *) which is safe. The C++
rules do allow it and hopefully the next major C language revision will
fix this.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------